On Tue, Apr 21, 2020 at 8:56 AM Kent Watsen <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
