Hi Benoit, On Thu, Jan 5, 2017 at 6:45 AM, Benoit Claise <[email protected]> wrote:
> 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. > Sure, the template does help since stating they are sensitive is similar enough to stating revealing information is possible. We wouldn't care if it wasn't sensitive or could help an attacker. > > Regarding the "listing this threat would be helpful.", I'm not convinced > that this is necessary to change the security guidelines YANG template. > Yes, please do use the template. I think because aSue asked about a specific template to I2RS, I was thrown a bit. The YANG template would be appropriate and they should also include links to any I2RS documents that contain relevant security considerations. Thank you, Kathleen > 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. > > > > > . > > > > -- Best regards, Kathleen
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
