Re: [netmod] Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)

Qin Wu <bill.wu@huawei.com> Sat, 09 May 2020 01:19 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940C33A0484; Fri, 8 May 2020 18:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 OSlBBNpi5imA; Fri, 8 May 2020 18:18:55 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 007C73A0418; Fri, 8 May 2020 18:18:54 -0700 (PDT)
Received: from lhreml709-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 0E01B9925251B2A6DD7D; Sat, 9 May 2020 02:18:52 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Sat, 9 May 2020 02:18:51 +0100
Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Sat, 9 May 2020 02:18:51 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.134]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Sat, 9 May 2020 09:18:45 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Roman Danyliw <rdd@cert.org>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, Kent Watsen <kent+ietf@watsen.net>, "draft-ietf-netmod-factory-default@ietf.org" <draft-ietf-netmod-factory-default@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, The IESG <iesg@ietf.org>
Thread-Topic: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)
Thread-Index: AdYln7iwAzZrMJvDROye81CUt2Ni7A==
Date: Sat, 9 May 2020 01:18:45 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD68DE17@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.33.123]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/uTRM1H8-MNg2xBrgi6oul0HLv9k>
Subject: Re: [netmod] Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 May 2020 01:19:04 -0000

Thanks Roman.

-Qin
-----邮件原件-----
发件人: Roman Danyliw [mailto:rdd@cert.org] 
发送时间: 2020年5月9日 4:16
收件人: Qin Wu <bill.wu@huawei.com>om>; Rob Wilton (rwilton) <rwilton@cisco.com>
抄送: netmod-chairs@ietf.org; Kent Watsen <kent+ietf@watsen.net>et>; draft-ietf-netmod-factory-default@ietf.org; netmod@ietf.org; The IESG <iesg@ietf.org>
主题: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)

Hi Qin!

Top posting to say thanks for the updated texted that was added to -15.  It addresses my DISCUSS points.

Regards,
Roman

> -----Original Message-----
> From: Qin Wu <bill.wu@huawei.com>
> Sent: Saturday, April 25, 2020 11:00 PM
> To: Rob Wilton (rwilton) <rwilton@cisco.com>om>; Roman Danyliw 
> <rdd@cert.org>
> Cc: netmod-chairs@ietf.org; Kent Watsen <kent+ietf@watsen.net>et>; 
> draft-ietf- netmod-factory-default@ietf.org; netmod@ietf.org; The IESG 
> <iesg@ietf.org>
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14:
> (with DISCUSS and COMMENT)
> 
> -----邮件原件-----
> 发件人: Rob Wilton (rwilton) [mailto:rwilton@cisco.com]
> 发送时间: 2020年4月25日 0:54
> 收件人: Qin Wu <bill.wu@huawei.com>om>; Roman Danyliw <rdd@cert.org>
> 抄送: netmod-chairs@ietf.org; Kent Watsen <kent+ietf@watsen.net>et>; draft- 
> ietf-netmod-factory-default@ietf.org; netmod@ietf.org; The IESG 
> <iesg@ietf.org>
> 主题: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14:
> (with DISCUSS and COMMENT)
> 
> Hi Qin,
> 
> This document was discussed today.  I think that Roman plans to follow 
> up regarding the security considerations discuss.
> 
> From the discussion today, and reading the Discuss, my understanding 
> is that Roman has two concerns that are more about the specific text 
> than the use of the template:
> 
> 1) Concerns read access to the factory-default datastore which could 
> contain sensitive information.  Perhaps read access to that datastore 
> should default to nacm:default-deny-all?  If so, then this should 
> probably be documented in section 3, with a sentence in section 6 to explain that is how it is protected.
> 
> [Qin]: Please See Jurgen and Andy's comment in this thread, I agree 
> with Jurgen we should treat factory in the same way as running and 
> other datastores. If any text is needed, I could add a few text in the 
> section 6 based on the discussion in this thread:
> "
> Access to the "factory-reset" RPC operation and factory default values 
> of all configuration data nodes within "factory-default" datastore is 
> considered sensitive and therefore has been restricted using the 
> "default-deny-all" access control defined in [RFC8341].
> "
> 2) The second point is asking to expand this paragraph:
> 
>    The operational disruption caused by setting the config to factory
>    default contents varies greatly depending on the implementation and
>    current config.
> 
> Such that the description also covers "Please note that a default 
> configuration could be insecure or not have security controls enabled 
> whereby exposing the network to compromise."
> 
> [Qin]:So we will see exposing factory default configuration to the 
> network to compromise also as one kind of operational disruption, if 
> this is true, here is the proposed change:
> OLD TEXT:
> "
>    The operational disruption caused by setting the config to factory
>    default contents varies greatly depending on the implementation and
>    current config.
> "
> NEW TEXT:
> "
> The operational disruption caused by setting the config to factory 
> default contents or lacking appropriate security control on factory 
> default configuration varies greatly depending on the implementation 
> and current config.
> "
> If not, please advise.
> 
> I see that you are already addressing the other comments that have 
> been raised.
> 
> Regards,
> Rob
> 
> 
> > -----Original Message-----
> > From: iesg <iesg-bounces@ietf.org> On Behalf Of Qin Wu
> > Sent: 21 April 2020 14:20
> > To: Roman Danyliw <rdd@cert.org>rg>; The IESG <iesg@ietf.org>
> > Cc: netmod-chairs@ietf.org; Kent Watsen <kent+ietf@watsen.net>et>; 
> > draft- ietf-netmod-factory-default@ietf.org; netmod@ietf.org
> > Subject: RE: Roman Danyliw's Discuss on
> > draft-ietf-netmod-factory-default-
> > 14: (with DISCUSS and COMMENT)
> >
> > Hi, Roman:
> > A few clarification inline below.
> > -----邮件原件-----
> > 发件人: Roman Danyliw via Datatracker [mailto:noreply@ietf.org]
> > 发送时间: 2020年4月21日 20:52
> > 收件人: The IESG <iesg@ietf.org>
> > 抄送: draft-ietf-netmod-factory-default@ietf.org;
> > netmod-chairs@ietf.org; netmod@ietf.org; Kent Watsen 
> > <kent+ietf@watsen.net>et>; kent+ietf@watsen.net
> > 主题: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14:
> > (with DISCUSS and COMMENT)
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-netmod-factory-default-14: Discuss
> >
> > When responding, please keep the subject line intact and reply to 
> > all email addresses included in the To and CC lines. (Feel free to 
> > cut this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-netmod-factory-default/
> >
> >
> >
> > --------------------------------------------------------------------
> > --
> > DISCUSS:
> > --------------------------------------------------------------------
> > --
> >
> > Please use YANG security considerations template from 
> > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.
> > Specifically (as a DISCUSS item):
> >
> > ** (Per the template questions “for all YANG modules you must 
> > evaluate whether any readable data”) Would factory-default contain 
> > any sensitive information in certain network environments where the 
> > ACLs should be more restrictive that world readable for everyone?
> > [Qin]: It does follows yang-security-guidelines but there is no 
> > readable data node defined within rpc, that's why we don't use third 
> > paragraph boilerplate and fourth paragraph boilerplate of 
> > yang-security-
> guidelines.
> > YANG-security-guidelines are more applicable to YANG data model with 
> > more readable/writable data nodes.
> > In addition, as clarified in the second paragraph, section 6 of this 
> > draft, NACM can be used to restrict access for particular NETCONF or 
> > RESTCONF users to a preconfigured subset of all available NETCONF or 
> > RESTCONF protocol operations (i.e., factory-reset rpc)
> >
> > Per “The operational disruption caused by setting the config to 
> > factory default contents varies greatly depending on the 
> > implementation and current config”, it seems like it could be worse 
> > than just an operational disruption.  Please note that a default 
> > configuration could be insecure or not have security controls 
> > enabled whereby exposing the network to compromise.
> >
> > [Qin]: As described in the second paragraph of section 6 it by 
> > default restrict access for everyone by using the "default-deny-all" 
> > access control defined [RFC8341], what else does it need to address 
> > this security concern?
> > --------------------------------------------------------------------
> > --
> > COMMENT:
> > --------------------------------------------------------------------
> > --
> >
> > Please use YANG security considerations template from 
> > https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines.
> > Specifically (as a COMMENT item):
> >
> > ** Add “The Network Configuration Access Control Model (NACM) 
> > [RFC8341] provides the means to …”
> >
> > [Qin]: We did follow this template, I am wondering how it is 
> > different from the second paragraph of section 6? I see they are 
> > equivalent but with more fine granularity security measures, if my understanding is correct.