On 1/4/2017 10:33 PM, Kathleen Moriarty wrote:
Kathleen Moriarty has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: 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:
----------------------------------------------------------------------
Thanks for your work on this draft.
I have a couple of things I'd like to discuss that may require some
additional text, but should be easy to resolve.
1. Privacy considerations - I don't see any listed and the YANG module
include a few identifiers as well as ways to group devices. I think
privacy considerations need to be added for use of this module.
2. Security - the network topology and inventory created by this module
reveals information about systems and services. This could be very
helpful information to an attacker and should also be called out as a
security consideration. The access and transport of this information is
covered though in the considerations, just listing this threat would be
helpful.
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines template
should be applied (I mentioned that in a previous review).
The first paragraph of the Security Considerations is right, but the
rest of the section doesn't quite follow the template (which is
something that the RFC editor will check).
For example, the following should be copied verbatim:
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:
And <list subtrees and data nodes and state why they are sensitive>
should be populated, based on the second paragraph of the current
Security Considerations.
Regarding your point "the network topology and inventory created by this
module reveals information about systems and services. This could be
very helpful information to an attacker and should also be called out as
a security consideration.", I believe that this is covered by the
previous paragraph. as most nodes are config-true.
Regarding the "listing this threat would be helpful.", I'm not convinced
that this is necessary to change the security guidelines YANG template.
As a comparison on how we've been documenting security considerations
for MIB modules, see https://trac.ietf.org/trac/ops/wiki/mib-security
Regards, Benoit
Thank you.
.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
