Hi Sue, Thanks for your quick and detailed response. inline
On Wed, Jan 4, 2017 at 6:52 PM, Susan Hares <[email protected]> wrote: > Kathleen: > > > > I'm confused by your request. I thought > draft-ietf-i2rs-protocol-security-requirements-17.txt > was written to answer this questions for all I2RS modules. We knew this > new style of interface with Yang modules had these privacy and security > constraints. This data module SHOULD only run under the protocol security > constraints listed in the > draft-ietf-i2rs-protocol-security-requirements-17.txt > module. This document left out of this yang module because I thought we > covered in the global document. Each of the I2RS global modules provides > information will have these concerns. > I just looked again and there is no reference to the requirements document in the security considerations section that says, look here for the additional security and privacy considerations. That's why it didn't occur to me when reading the draft. > Let me review these concerns: > > > > · Topology modules - you correctly note that the draft > -i2rs-yang-network-topology model has privacy concerns regarding the > identifiers and grouping of devices. You also correctly note that network > topology and network inventory can be used to attack the modules. > > You may want to call out the specific identifiers (in a list) in the security considerations section when you reference the security requirements draft. It's helpful to have specifics about a draft called out that go beyond the general requirements document. > > > · RIB modules - You should understand the I2RS RIB has grouping > and names that could be used to identify groups of routes. In addition, > RIB information quickly inserted/pulled from nodes is an attack vector. > > > > · FB RIB module - The filter based RIBS indicates the filters > that control forwarding of data on selected interfaces. It uses group > names to group these filters for companies or to group filters by > function. You can expand the topology concerns to the filters as well. > Please do call out these concerns explicitly. It may help developers and implementers. > > > · The I2NSF data modules build upon these concepts. > > > > Do you wish threat sections in each module? Could you provide a template > for these threat comments. If you wish to limit group identifiers in all > of these modules, it would be good to provide write-up on what is good/bad > group identifiers so the authors provide the > I called out identifiers specifically as this document had a few and that is something to watch for per RFC6973. Your other comments are helpful and would aid a reader. > > > In future SEC-DIR reviews, it would be good for your reviewers to > specifically examine the document to see if these issues have been > addressed. > Yes, if you'd like to add the concerns that have come up in the recent document reviews to the discussion on the SAAG list for 3552, that would be very helpful. That document needs revision, but really needs input from cross area contributors as they are the intended audience. Please help us get that draft to a state that it assists editors from other areas. Thank you, Kathleen > > > Sue Hares (shepherd) > > > > > > ============== > > > > 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. > > > > > > -----Original Message----- > From: Kathleen Moriarty [mailto:[email protected]] > Sent: Wednesday, January 4, 2017 4:34 PM > To: The IESG > Cc: [email protected]; Susan Hares; > [email protected]; [email protected]; [email protected] > Subject: Kathleen Moriarty's Discuss on draft-ietf-i2rs-yang-network-topo-10: > (with DISCUSS) > > > > 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. > > > > Thank you. > > > > > > > > > -- Best regards, Kathleen
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
