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

Andy Bierman <andy@yumaworks.com> Fri, 24 April 2020 18:27 UTC

Return-Path: <andy@yumaworks.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 87C363A0063 for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2020 11:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 Mw7XOFiwCcJy for <netmod@ietfa.amsl.com>; Fri, 24 Apr 2020 11:27:11 -0700 (PDT)
Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A443A00C0 for <netmod@ietf.org>; Fri, 24 Apr 2020 11:27:11 -0700 (PDT)
Received: by mail-yb1-xb2f.google.com with SMTP id f13so5536034ybk.7 for <netmod@ietf.org>; Fri, 24 Apr 2020 11:27:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ArLAPgZiuOc7r65xVf9r6ivKJFXMzIS9JM44Y/xMNrI=; b=FiJ3/G3HYxfS3zF2hNBl+H88UW+YcK5C3UDA/LI5JZ036Jz+qDOX1IOlW8dge6jvLX tJFdUGcS9zeoi9H9aYZT0Zg5kNx0PNfVY9ro6SG8+/OoU3AO9XOIfteGCzQ/ETejprFL g5quJ/b+pxLArPZuRDFLSwlfW+lrwKZeGI4cBiHSLbHMMLg29f2GSzwfiq6nQbOVn1wm 0d9oiRa+vKd4Oqde4VjXFt2N2KlElclgvJwwFss4JYNa+kENjQPHFiG6uLzcFZmtkVBR lxwCfQl5T4DLOJ3Dzb+iEq0+xvQMhFlWQ4PT+5ZKk/a/qhxREEeJDm8W0W5PDn/pJ3EJ PQ/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ArLAPgZiuOc7r65xVf9r6ivKJFXMzIS9JM44Y/xMNrI=; b=JWKfSdoSy+D2SPoUepmpx+cqhFRESDlYYbN/AFvKi6bPcxARJQKy5dgc6oEWugCz3v et5N1tB+SN8jaR/qP/nqas25KqsTPjhZMRJ3pcE6js1DJZGVpepaOa0iSFc4s0cFdMYE OXlyMTCDgWvW6TxgIey93bmq3P4Qf8hp1BtSzvBzXKI5pytfwHTiFljwV/5Zq+POphfF 12o1Z9e2M5lccZJggzqnHhszYvCg/SFcV2SFIxkTUGJqLURh4OnrZQVAkrsO4iYU4TzM FXq8emOQqc2EP9Gt32w01hdM8mwnZI/kS7EEr9SNPkJ8pYfvDrO/Snqqswi8MmWGK4aA fV5Q==
X-Gm-Message-State: AGi0PuZ59goY/MKBWHe0PPMhln+J/gwosAuAM5tx8Nd1QipTpxI/Nq6s 5fFaG35XSh53fXZDzabo9AXPbwLupaniPHhXDcyOPg==
X-Google-Smtp-Source: APiQypK22OFZJp9b1cSCnxPwa7jviAm1CovxBkKlOHMOL/HSvtRmoQ7td8oyul4Se3C6bBVlBkZMDqYaJJ94XDcZzvc=
X-Received: by 2002:a25:158a:: with SMTP id 132mr15685416ybv.145.1587752830066; Fri, 24 Apr 2020 11:27:10 -0700 (PDT)
MIME-Version: 1.0
References: <B8F9A780D330094D99AF023C5877DABAAD620C2A@dggeml511-mbx.china.huawei.com> <MN2PR11MB436656E179DA492EA53477A3B5D00@MN2PR11MB4366.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB436656E179DA492EA53477A3B5D00@MN2PR11MB4366.namprd11.prod.outlook.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 24 Apr 2020 11:26:59 -0700
Message-ID: <CABCOCHREPy=0yfWXNfh7BictX6qdwZao6ZKE-LhvhTh6yix9DQ@mail.gmail.com>
To: "Rob Wilton (rwilton)" <rwilton=40cisco.com@dmarc.ietf.org>
Cc: Qin Wu <bill.wu@huawei.com>, Roman Danyliw <rdd@cert.org>, "netmod-chairs@ietf.org" <netmod-chairs@ietf.org>, "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>
Content-Type: multipart/alternative; boundary="0000000000006d7b6b05a40d833d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WDiTvIiLiwj_7RxDkLkg1WMj6lA>
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: Fri, 24 Apr 2020 18:27:15 -0000

On Fri, Apr 24, 2020 at 9:54 AM Rob Wilton (rwilton) <rwilton=
40cisco.com@dmarc.ietf.org> wrote:

> 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.
>
>
The security risk here depends on the server implementation.
In the simplest use cases the factory config may be empty (i.e., just YANG
defaults).
This might even occur for complex NMDA implementations because <intended>
contains all the implementation details and factory <running> could be
empty.

I am just asking for a little text in the SC section that says the
factory-default datastore
could contain sensitive configuration data nodes, and the risk depends on
the
specific YANG data nodes present in the server.




> 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."
>
> I see that you are already addressing the other comments that have been
> raised.
>
>

Our server supports a "fallback to factory-default" boot mode.
If the server boots with a bad configuration it can retry with the factory
default config.

Does there need to be any mention that the server MAY invoke the
<factory-reset> operation on its own?

Was there any discussion of a "factory-reset" notification during
development?
Seems like factory-reset of a device is an interesting management event.


Regards,
> Rob
>
>

Andy


>
> > -----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.
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>