[i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-network-topo-15: (with DISCUSS and COMMENT)

[Benoit Claise <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-15: 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-i2rs-yang-network-topo/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Preliminary note: I hope I'm doing the right thing by updating this DISCUSS
point as  I understand that the document is back to the WG. However, since I
reviewed the version 15, since some of my ballot points have been addressed
(thank you), and since I wanted to share my feedback publicly, here is my
feedback.

Please follow the YANG security guidelines template at
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines

        There are a number of data nodes defined in this YANG module that are
        writable/creatable/deletable (i.e., config true, which is the default).
        These data nodes may be considered sensitive or vulnerable in some
        network environments. Write operations (e.g., edit-config) to these
        data nodes without proper protection can have a negative effect on
        network operations. These are the subtrees and data nodes and their
        sensitivity/vulnerability:

        <list subtrees and data nodes and state why they are sensitive>

        -- for all YANG modules you must evaluate whether any readable data --
        nodes (those are all the "config false" nodes, but also all other --
        nodes, because they can also be read via operations like get or --
        get-config) are sensitive or vulnerable (for instance, if they -- might
        reveal customer information or violate personal privacy -- laws such as
        those of the European Union if exposed to -- unauthorized parties)

        Some of the readable data nodes in this YANG module may be considered
        sensitive or vulnerable in some network environments. It is thus
        important to control read access (e.g., via get, get-config, or
        notification) to these data nodes. These are the subtrees and data
        nodes and their sensitivity/vulnerability:

        <list subtrees and data nodes and state why they are sensitive>

        -- if your YANG module has defined any rpc operations -- describe their
        specific sensitivity or vulnerability.

        Some of the RPC operations in this YANG module may be considered
        sensitive or vulnerable in some network environments. It is thus
        important to control access to these operations. These are the
        operations and their sensitivity/vulnerability:

        <list RPC operations and state why they are sensitive>

I don't understand why the security considerations section of a YANG module
document speaks about this:

    Rules expressed in NACM can be applied analogously also to other
       protocols that attempt access to YANG-defined data.  In fact, it
       needs to be applied in the same way and should, like YANG, thus be
       considered independent of any particular protocol that is used to
       access YANG-defined data.  Otherwise, access control rules defined by
       NACM could be very easily circumvented simply by using another access
       mechanism which does not enforce NACM.  The alternative of mandating
       the introduction of mechanisms parallel to NACM that specify the same
       access control rules for other transports is clearly undesirable, as
       this would not only inhibit ease-of-use of systems that implement
       multiple protocols to access YANG data, but also open the specter of
       security holes due to inconsistencies in articulation and enforcement
       of rules across mechanisms that are essentially redundant.

This is even confusing to speak about other protocols before/without specifying
those protocols. You should remove this.

OLD DISCUSS, FOR INFORMATION ONLY:
To make sure both draft-ietf-i2rs-yang-network-topo and
draft-ietf-i2rs-yang-l3-topology are treated the same way, here is my DISCUSS.
As background, email sent to I2RS/IESG on Jan 24th 2017

Let me repeat what I mentioned already on the I2RS mailing list:

    This document contains a YANG model, a generic YANG model that could be
    accessed by NETCONF, RESTCONF, or the future I2RS protocol. This document
    doesn't say (and that would be a mistake IMO if it would) that this YANG
    model can only be accessed by the I2RS protocol. Hence I'm advocating that
    the security considerations diligently follow
    https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, and that they
    don't go in the I2RS protocol specific details.

This comment was made for draft-ietf-i2rs-yang-network-topo, but is equally
applicable to this draft-ietf-i2rs-yang-l3-topology draft. I still maintain
this point of view: it would be a mistake to limit a data model usage to a
particular protocol. These topology documents are not I2RS YANG models, these
are YANG models, which can be used in different contexts. I'm very concerned if
we start having per-WG or per context data models in the IETF. Btw, I haven't
seen a RFC specifying what the I2RS protocol is, only the requirements. We
can't modify the current generic YANG security considerations for an I2RS
control plane and a new datastore that are not yet specified. If you want to
describe how I2RS will be using those topology YANG models (and any YANG models
btw), then it's suitable to include this part of the I2RS protocol spec or part
of an I2RS applicability statement. This is typically where you would describe
some protocol specific information such as "write contention for two clients
writing a node using I2RS priority (linked to I2RS User-ID)".

Let me make my point differently. Let's assume for a moment that I2RS needs to
use the IETF interface YANG model, does it mean that you will require RFC
7223bis with an updated security considerations? This can't be.

I still think the generic YANG security guidelines is suitable, as it relates
to IETF specified protocols NETCONF and RESTCONF. Addition of some generic
information about the data model (not I2RS protocol) might be useful though.
For example, text around "there is a risk that a write to a topology may create
a looping topology or overload a particular node". Note that I don't think the
the security considerations is the best section for this though.

Regards, Benoit


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial:

     The data model obeys the requirements for the ephemeral state found
       in the document [I-D.draft-ietf-i2rs-ephemeral-state].  For ephemeral
       topology data that is system controlled, the process tasked with
       maintaining topology information will load information from the
       routing process (such as OSPF) into the <operational> without relying
       on a configuration datastore.

    <operational> =>  operational state datastore,
    according to https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/