Hello, I had placed this on the telechat in a little over 2 weeks. If there is no response and update today, I will have to move it until after Singapore as the IETF last call takes 2 weeks and I'd like a couple of days after that completes prior to the telechat. Please let me know the status so I can adjust telechat dates or start the IETF last call.
Thank you, Kathleen On Mon, Oct 2, 2017 at 4:59 PM, Kathleen Moriarty <[email protected]> wrote: > Hello, > > Thank you for your work on this document! I know it underwent many > revisions and it can be difficult to merge text pulling together ideas > from numerous contributors. The draft is well written and easy to > understand, thank you for all your hard work, it shows! > > Now to a few comments I'd like to see if we can clear up before > starting last call. > > Section 5 begins with the following text: > > An important concept underlying this framework is the fact that > attackers do not have standards as to how to attack networks, so it > is equally important to not constrain NSF developers to offering a > limited set of security functions. In other words, the introduction > of I2NSF standards should not make it easier for attackers to > compromise the network. > > I think the first sentence could be safely dropped and the second > sentence altered to something like the following: > > A basic tenet in the introduction > of I2NSF standards is that he standards should not make it easier > for attackers to > compromise the network. > > You may get comments on the following point, also in section 5: > > o Be seen as endorsing a best common practice for the implementation > of NSFs > > But, I am not going to suggest a change yet. I could see further > explanation being needed for the text. > > Section 7.1 > > I'd suggest using a different example for the time constraints, a > business one would be better. The one listed for a home user could > have the reader jump to censorship concerns if this is targeted to > home users. How about an ERP system is allowed to be accessed from > the corporate network only during business hours for a high privileged > class of users? Outside of the times could indicate an attack and > you'd want that access approved if there was an extenuating > circumstance. > > Do you plan to allow for rule setting to be extended to home users? I > think that will raise concern as I thought scope was limited to > enterprises with cloud service offerings. > > Section 8: > s/I2NSF system can explose/I2NSF system can expose/ > > Section 11. > > Since this is the framework, the security considerations are fine, but > you do need to add a privacy considerations section. I can see a few > possible privacy concerns and there may be more that I am missing. > > Privacy of end users with the reporting options. If all of the fields > described in section 10 could be used in reports, you have a lot of > interesting tracking information that is now easily accessible with > quick reports. The ability to leave out identifying information will > be important as will having ways to protect that data at rest as well > as in transit. > > I2NSF could also be used in targeted ways toward individuals in attack > scenarios, both an invasion of privacy and a security consideration > for the attack possibilities. If home use is not out-of-scope, you'll > have real issues here and it will be really hard to tackle the > security and privacy concerns. > > The I2NSF user information could be sensitive too - meaning the person > doing provisioning. What protects their account information (I think > you have this covered), you may want to state it for privacy reasons. > > Thanks! > -- > > Best regards, > Kathleen -- Best regards, Kathleen _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
