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

[Qin Wu]

Yes, Rob, all comments are addressed in v-15, ready to go, I believe.
发件人： Rob Wilton (rwilton)mailto:rwil...@cisco.com>>
收件人： Qin Wumailto:bill...@huawei.com>>
抄送： netmod-chairsmailto:netmod-cha...@ietf.org>>;Kent 
Watsenmailto:kent+i...@watsen.net>>;draft-ietf-netmod-factory-defaultmailto:draft-ietf-netmod-factory-defa...@ietf.org>>;netmodmailto:netmod@ietf.org>>;The
 IESGmailto:i...@ietf.org>>
主题： RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with 
DISCUSS and COMMENT)
时间： 2020-05-11 21:15:16

Qin,

Please can you confirm that -15 addresses all IESG comments and directorate 
review comments, and this version is ready to go.

Regards,
Rob


> -Original Message-
> From: Qin Wu 
> Sent: 09 May 2020 02:19
> To: Roman Danyliw ; Rob Wilton (rwilton) 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> 
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-
> 14: (with DISCUSS and COMMENT)
>
> Thanks Roman.
>
> -Qin
> -邮件原件-
> 发件人: Roman Danyliw [mailto:r...@cert.org]
> 发送时间: 2020年5月9日 4:16
> 收件人: Qin Wu ; Rob Wilton (rwilton)
> 
> 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> 
> 主题: 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 
> > Sent: Saturday, April 25, 2020 11:00 PM
> > To: Rob Wilton (rwilton) ; Roman Danyliw
> > 
> > Cc: netmod-cha...@ietf.org; Kent Watsen ;
> > draft-ietf- netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> > 
> > Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-
> default-14:
> > (with DISCUSS and COMMENT)
> >
> > -邮件原件-
> > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > 发送时间: 2020年4月25日 0:54
> > 收件人: Qin Wu ; Roman Danyliw 
> > 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft-
> > ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> > 
> > 主题: 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:
> > "
> >

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

[Rob Wilton (rwilton)]

Qin,

Please can you confirm that -15 addresses all IESG comments and directorate 
review comments, and this version is ready to go.

Regards,
Rob


> -Original Message-
> From: Qin Wu 
> Sent: 09 May 2020 02:19
> To: Roman Danyliw ; Rob Wilton (rwilton) 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> 
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-
> 14: (with DISCUSS and COMMENT)
> 
> Thanks Roman.
> 
> -Qin
> -邮件原件-
> 发件人: Roman Danyliw [mailto:r...@cert.org]
> 发送时间: 2020年5月9日 4:16
> 收件人: Qin Wu ; Rob Wilton (rwilton)
> 
> 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> 
> 主题: 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 
> > Sent: Saturday, April 25, 2020 11:00 PM
> > To: Rob Wilton (rwilton) ; Roman Danyliw
> > 
> > Cc: netmod-cha...@ietf.org; Kent Watsen ;
> > draft-ietf- netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> > 
> > Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-
> default-14:
> > (with DISCUSS and COMMENT)
> >
> > -邮件原件-
> > 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> > 发送时间: 2020年4月25日 0:54
> > 收件人: Qin Wu ; Roman Danyliw 
> > 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft-
> > ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> > 
> > 主题: 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  On Behalf Of

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

[Qin Wu]

Thanks Roman.

-Qin
-邮件原件-
发件人: Roman Danyliw [mailto:r...@cert.org] 
发送时间: 2020年5月9日 4:16
收件人: Qin Wu ; Rob Wilton (rwilton) 
抄送: netmod-cha...@ietf.org; Kent Watsen ; 
draft-ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 

主题: 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 
> Sent: Saturday, April 25, 2020 11:00 PM
> To: Rob Wilton (rwilton) ; Roman Danyliw 
> 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; 
> draft-ietf- netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 
> 
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14:
> (with DISCUSS and COMMENT)
> 
> -邮件原件-
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2020年4月25日 0:54
> 收件人: Qin Wu ; Roman Danyliw 
> 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft- 
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 
> 
> 主题: 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  On Behalf Of Qin Wu
> > Sent: 21 April 2020 14:20
> > To: Roman Danyliw ; The IESG 
> > Cc: netmod-cha...@ietf.org; Kent Watsen ; 
> > draft- ietf-netmod-factory-defa...@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:nore...@ietf.org]
> > 发送时间: 2020年4月21日 20:52
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org;
> > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> > ; kent+i...@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,

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

[Roman Danyliw]

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 
> Sent: Saturday, April 25, 2020 11:00 PM
> To: Rob Wilton (rwilton) ; Roman Danyliw 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-ietf-
> netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14:
> (with DISCUSS and COMMENT)
> 
> -邮件原件-
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2020年4月25日 0:54
> 收件人: Qin Wu ; Roman Danyliw 
> 抄送: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG
> 
> 主题: 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  On Behalf Of Qin Wu
> > Sent: 21 April 2020 14:20
> > To: Roman Danyliw ; The IESG 
> > Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-
> > ietf-netmod-factory-defa...@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:nore...@ietf.org]
> > 发送时间: 2020年4月21日 20:52
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org;
> > netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen
> > ; kent+i...@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 C

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

[Qin Wu]

Hi, Roman:
Please review the diff and see if your comments are addressed and your DISCUSS 
can be cleared.
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-factory-default-15
Thanks!

-Qin
-邮件原件-
发件人: Qin Wu 
发送时间: 2020年4月26日 11:00
收件人: 'Rob Wilton (rwilton)' ; Roman Danyliw 
抄送: netmod-cha...@ietf.org; Kent Watsen ; 
draft-ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 

主题: RE: Roman Danyliw's Discuss on draft-ietf-netmod-factory-default-14: (with 
DISCUSS and COMMENT)

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2020年4月25日 0:54
收件人: Qin Wu ; Roman Danyliw 
抄送: netmod-cha...@ietf.org; Kent Watsen ; 
draft-ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 

主题: 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  On Behalf Of Qin Wu
> Sent: 21 April 2020 14:20
> To: Roman Danyliw ; The IESG 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft- 
> ietf-netmod-factory-defa...@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:nore...@ietf.org]
> 发送时间: 2020年4月21日 20:52
> 收件人: The IESG 
> 抄送: draft-ietf-netmod-factory-defa...@ietf.org;
> netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> ; kent+i...@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):
> 
> 

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

[Qin Wu]

-邮件原件-
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com] 
发送时间: 2020年4月25日 0:54
收件人: Qin Wu ; Roman Danyliw 
抄送: netmod-cha...@ietf.org; Kent Watsen ; 
draft-ietf-netmod-factory-defa...@ietf.org; netmod@ietf.org; The IESG 

主题: 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  On Behalf Of Qin Wu
> Sent: 21 April 2020 14:20
> To: Roman Danyliw ; The IESG 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft- 
> ietf-netmod-factory-defa...@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:nore...@ietf.org]
> 发送时间: 2020年4月21日 20:52
> 收件人: The IESG 
> 抄送: draft-ietf-netmod-factory-defa...@ietf.org; 
> netmod-cha...@ietf.org; netmod@ietf.org; Kent Watsen 
> ; kent+i...@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-s

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

[Andy Bierman]

On Fri, Apr 24, 2020 at 9:54 AM Rob Wilton (rwilton)  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 
contains all the implementation details and factory  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
 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  On Behalf Of Qin Wu
> > Sent: 21 April 2020 14:20
> > To: Roman Danyliw ; The IESG 
> > Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-
> > ietf-netmod-factory-defa...@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:nore...@ietf.org]
> > 发送时间: 2020年4月21日 20:52
> > 收件人: The IESG 
> > 抄送: draft-ietf-netmod-factory-defa...@ietf.org; netmod-cha...@ietf.org;
> > netmod@ietf.org; Kent Watsen ;
> kent+i...@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 c

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

[Juergen Schoenwaelder]

On Fri, Apr 24, 2020 at 04:54:04PM +, Rob Wilton (rwilton) wrote:
> 
> 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.
>

Why would a factory-default datastore be more sensitive than ?

/js

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

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.

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.

Regards,
Rob


> -Original Message-
> From: iesg  On Behalf Of Qin Wu
> Sent: 21 April 2020 14:20
> To: Roman Danyliw ; The IESG 
> Cc: netmod-cha...@ietf.org; Kent Watsen ; draft-
> ietf-netmod-factory-defa...@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:nore...@ietf.org]
> 发送时间: 2020年4月21日 20:52
> 收件人: The IESG 
> 抄送: draft-ietf-netmod-factory-defa...@ietf.org; netmod-cha...@ietf.org;
> netmod@ietf.org; Kent Watsen ; kent+i...@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 

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

[Kent Watsen]

[Roman: for this draft, the takeaway is that Qin’s section deviates from the 
template because the module doesn’t define all the parts typically found in a 
YANG module]


Hi Rob,

> [RW]
> Perhaps add such as section in [], and mark it to be removed before 
> publication.
>  
> E.g. [RFC Editor: Please remove this comment before publication. For 
> reviewers:  This section has been modified from the standard template because 
> …]

Yes, this idea was coming to me as I was writing the above, but I thought it 
useful still to agree that the RFCs should never be published with a reference 
to the template, whether or not the Security Considerations section conforms to 
it or not.


> I’m obviously not saying that we need to do this for this document, just as a 
> suggestion for future documents.

Agreed.

>  
> Regards,
> Rob

Kent  // as chair and shepherd


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Rob Wilton (rwilton)]

Hi Kent,


From: netmod  On Behalf Of Kent Watsen
Sent: 21 April 2020 16:56
To: Qin Wu 
Cc: Roman Danyliw ; netmod-cha...@ietf.org; The IESG 
; netmod@ietf.org; draft-ietf-netmod-factory-defa...@ietf.org
Subject: Re: [netmod] Roman Danyliw's Discuss on 
draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)

Hi Roman,

--
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.


Regarding the use of the YANG security considerations template from [1], it has 
been noted that the template is imperfect in several ways…

For instance, a YANG module  may not define any protocol accessible nodes 
(e.g., they only define identities, typedefs, yang-data, or structures).  In 
another example, the YANG module may only define RPCs (such as in this case) 
and/or notifications.  In yet another example, the YANG module may be only for 
use with RESTCONF (not NETCONF), and thus mentioning NETCONF at all would be 
odd (i.e., RFC 8572).

In such cases, strict adherence to the template does not make sense.  As 
chair/shepherd/author, I’ve struggled with how to best satisfy the intention 
adequately.   Of course, each case varies, but one idea that I’ve been 
exploring is to start the section with a disclaimer explaining why/how template 
[1] is (or not) followed.  This approach is appealing as it immediately conveys 
to the IESG that the template was not ignored.  However, it is unappealing in 
that it may be wrong for the published Security Considerations section to have 
a link to the template.
[RW]
Perhaps add such as section in [], and mark it to be removed before publication.

E.g. [RFC Editor: Please remove this comment before publication. For reviewers: 
 This section has been modified from the standard template because …]

I’m obviously not saying that we need to do this for this document, just as a 
suggestion for future documents.

Regards,
Rob


Please advise.
Kent  // as chair and shepherd

[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines





___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Qin Wu]

Hi,
发件人: Andy Bierman [mailto:a...@yumaworks.com]
发送时间: 2020年4月22日 0:20
收件人: Kent Watsen 
抄送: Qin Wu ; Roman Danyliw ; 
netmod-cha...@ietf.org; The IESG ; netmod@ietf.org; 
draft-ietf-netmod-factory-defa...@ietf.org
主题: Re: [netmod] Roman Danyliw's Discuss on 
draft-ietf-netmod-factory-default-14: (with DISCUSS and COMMENT)



On Tue, Apr 21, 2020 at 8:56 AM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:
Hi Roman,

--
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.


Regarding the use of the YANG security considerations template from [1], it has 
been noted that the template is imperfect in several ways…

For instance, a YANG module  may not define any protocol accessible nodes 
(e.g., they only define identities, typedefs, yang-data, or structures).  In 
another example, the YANG module may only define RPCs (such as in this case) 
and/or notifications.  In yet another example, the YANG module may be only for 
use with RESTCONF (not NETCONF), and thus mentioning NETCONF at all would be 
odd (i.e., RFC 8572).

In such cases, strict adherence to the template does not make sense.  As 
chair/shepherd/author, I’ve struggled with how to best satisfy the intention 
adequately.   Of course, each case varies, but one idea that I’ve been 
exploring is to start the section with a disclaimer explaining why/how template 
[1] is (or not) followed.  This approach is appealing as it immediately conveys 
to the IESG that the template was not ignored.  However, it is unappealing in 
that it may be wrong for the published Security Considerations section to have 
a link to the template.



Section 3 defines a factory-default datastore.
This exposes the factory default values of all configuration data nodes.
It seems like this should be mentioned in security considerations.

[Qin]: We could mention this but all other datastores defined in 
[RFC6241][RFC8342] could expose values of configuration data nodes. How it is 
different from other datastores, especially NMDA datastore, should it be 
treated differently? In addition, I think NACM is sufficient to prevent illegal 
access to content of various datastores. If any change is needed, we could make 
the following change:

OLD Text:

“

   Access to the "factory-reset" RPC operation is considered sensitive

   and therefore has been restricted using the "default-deny-all" access

   control defined in [RFC8341<https://tools.ietf.org/html/rfc8341>].
“
NEW TEXT:
“

   Access to the "factory-reset" RPC operation and content of factory-default 
datastore is considered sensitive

   and therefore has been restricted using the "

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

[Andy Bierman]

On Tue, Apr 21, 2020 at 8:56 AM Kent Watsen  wrote:

> Hi Roman,
>
> --
> 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.
>
>
>
> Regarding the use of the YANG security considerations template from [1],
> it has been noted that the template is imperfect in several ways…
>
> For instance, a YANG module  may not define any protocol accessible nodes
> (e.g., they only define identities, typedefs, yang-data, or structures).
> In another example, the YANG module may only define RPCs (such as in this
> case) and/or notifications.  In yet another example, the YANG module may be
> only for use with RESTCONF (not NETCONF), and thus mentioning NETCONF at
> all would be odd (i.e., RFC 8572).
>
> In such cases, strict adherence to the template does not make sense.  As
> chair/shepherd/author, I’ve struggled with how to best satisfy the
> intention adequately.   Of course, each case varies, but one idea that I’ve
> been exploring is to start the section with a disclaimer explaining why/how
> template [1] is (or not) followed.  This approach is appealing as it
> immediately conveys to the IESG that the template was not ignored.
> However, it is unappealing in that it may be wrong for the published
> Security Considerations section to have a link to the template.
>
>

Section 3 defines a factory-default datastore.
This exposes the factory default values of all configuration data nodes.
It seems like this should be mentioned in security considerations.

The template is a guideline, nothing more.

IMO even a typedef can require some security documentation:

   typedef password {
   type string;
   description
 "contains the text password for access to all confidential server
data";
   }



Please advise.
> Kent  // as chair and shepherd
>
>

Andy



> [1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
>
>
>
>
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Kent Watsen]

Hi Roman,

> --
> 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.


Regarding the use of the YANG security considerations template from [1], it has 
been noted that the template is imperfect in several ways…

For instance, a YANG module  may not define any protocol accessible nodes 
(e.g., they only define identities, typedefs, yang-data, or structures).  In 
another example, the YANG module may only define RPCs (such as in this case) 
and/or notifications.  In yet another example, the YANG module may be only for 
use with RESTCONF (not NETCONF), and thus mentioning NETCONF at all would be 
odd (i.e., RFC 8572).

In such cases, strict adherence to the template does not make sense.  As 
chair/shepherd/author, I’ve struggled with how to best satisfy the intention 
adequately.   Of course, each case varies, but one idea that I’ve been 
exploring is to start the section with a disclaimer explaining why/how template 
[1] is (or not) followed.  This approach is appealing as it immediately conveys 
to the IESG that the template was not ignored.  However, it is unappealing in 
that it may be wrong for the published Security Considerations section to have 
a link to the template.

Please advise.
Kent  // as chair and shepherd

[1] https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines 






___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

[Qin Wu]

Hi, Roman:
A few clarification inline below. 
-邮件原件-
发件人: Roman Danyliw via Datatracker [mailto:nore...@ietf.org] 
发送时间: 2020年4月21日 20:52
收件人: The IESG 
抄送: draft-ietf-netmod-factory-defa...@ietf.org; netmod-cha...@ietf.org; 
netmod@ietf.org; Kent Watsen ; kent+i...@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

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

[Roman Danyliw via Datatracker]

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?

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.


--
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 …”



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod