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] error on netmod page

[tom petch]

From: netmod  on behalf of Ladislav Lhotka 

Sent: 21 April 2020 16:03
Hi,

I just noticed that ancient draft draft-ietf-netmod-dsdl-00 suddenly 
re-appeared among Active Internet-Drafts on the netmod page

https://datatracker.ietf.org/wg/netmod/documents/

Has the datatracker gone mad? :-)


I-d-announce announced this I-D 19mar20 with a Date within the announcement of 
2008-07-07

Tom petch





Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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

[netmod] error on netmod page

[Ladislav Lhotka]

Hi,

I just noticed that ancient draft draft-ietf-netmod-dsdl-00 suddenly 
re-appeared among Active Internet-Drafts on the netmod page

https://datatracker.ietf.org/wg/netmod/documents/

Has the datatracker gone mad? :-)

Lada

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

[netmod] yang-module-versioning: max 1 revision label

[Sterne, Jason (Nokia - CA/Ottawa)]

Hi all,

We talked about this briefly on our YANG versioning weekly call today, but we 
should tighten up this statement down in the YANG module:

  Each 'revision' statement MAY have a single 'revision-label' 
substatement.

I'd propose this instead:

  Each 'revision' statement MUST NOT have more than a single 
'revision-label' substatement.

Similarly in the body of 3.3 we should change this:

   Each revision entry in a module or submodule MAY have a revision
   label associated with it, providing an alternative alias to identify
   a particular revision of a module or submodule.

to this:

   Each revision entry in a module or submodule MAY have a revision
   label associated with it, providing an alternative alias to identify
   a particular revision of a module or submodule. There MUST NOT be more
   than a single 'revision-label' substatement associated with a revision entry.

There is a similar minor ambiguity for these items as well:

  Each 'revision' statement MAY have a single 'nbc-changes' 
substatement.
  Each 'status' statement MAY have a single 'status-description' 
substatement.

Rgds,
Jason
___
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