Dear all,
Stephen:
Thank you for letting the authors know about your security concerns. I think
we have some discussion that needs to take place with the authors, Alia, and
Benoit on whether the yang security guidelines are sufficient or if these need
to be expanded based on the I2RS protocol security requirements.
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.
Regards, Benoit
I appreciate Kathleen, you, Ben, and Benoit mentioning the privacy and security
issues. It will help us make sure the next I2RS documents submitted to the
IESG have the appropriate security considerations and threat analysis.
On the 6 authors, we really did investigate each authors active contribution.
Sue Hares
Document shepherd.
-----Original Message-----
From: Stephen Farrell [mailto:[email protected]]
Sent: Thursday, January 5, 2017 7:52 AM
To: The IESG
Cc: [email protected]; Susan Hares;
[email protected]; [email protected]; [email protected]
Subject: Stephen Farrell's No Objection on
draft-ietf-i2rs-yang-network-topo-10: (with COMMENT)
Stephen Farrell has entered the following ballot position for
draft-ietf-i2rs-yang-network-topo-10: No Objection
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/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
I agree with Kathleen's discuss points and have one more aspect to offer that I
hope you include in that
discussion:
This model I think will lead designers to only think about the nodes that are
supposed to have access to traffic. (See also below about broadcast media.)
The model will generally not capture the reality that some other nodes can also
actually see or influence traffic and I think that will lead to vulnerabilities
not being recognised. I don't have a good suggestion for how to fix that
problem but I do think you ought mention it as a security consideration, e.g.
something
like: "For models such as these - the real world network may allow additional
communications or links that are not represented in the model and such links may enable
vulnerabilities that are liable to be missed when considering only the model. These
models don't really capture the security or privacy aspects of the network."
- 4.2 and generally: It is not clear to me how to represent broadcast media
(e.g. radio) nor how IP multicast would be reflected in this model. I assume
those can be done but as a bit of a hack.
- nit: 6 authors and 4 contributors. I wish people (esp chairs) would just
enforce the 5 author guideline and say why that's inappropriate in the few
instances in which that is the case.
.
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
